객체 지향 프로그래밍

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

객체 지향 프로그래밍(OOP)은 1960년대 초에 등장하여 널리 사용되는 프로그래밍 패러다임으로, 데이터를 캡슐화하고 코드 재사용성을 높이는 데 중점을 둔다. 시뮬라 67이 OOP의 시초로 여겨지며, 스몰토크, C++, 자바, 파이썬 등 다양한 언어에서 OOP가 지원된다. OOP는 클래스, 객체, 상속, 다형성, 동적 바인딩 등의 특징을 가지며, 자료 추상화, 캡슐화, 코드 재사용성 등의 장점을 제공한다. 그러나 OOP는 복잡성과 비효율성을 야기한다는 비판도 받으며, 최근에는 함수형 프로그래밍의 대안으로 제시되기도 한다.

더 읽어볼만한 페이지

프로그래밍 패러다임 - 지식 표현
지식 표현은 컴퓨터가 인간의 지식을 이해하고 활용하도록 정보를 구조화하는 기술이며, 표현력과 추론 효율성의 균형, 불확실성 처리 등을 핵심 과제로 다양한 기법과 의미 웹 기술을 활용한다.
프로그래밍 패러다임 - 의도적 프로그래밍
의도적 프로그래밍은 프로그래머의 의도를 명확히 포착하고 활용하여 소프트웨어 개발 생산성을 향상시키기 위한 프로그래밍 패러다임으로, 트리 기반 저장소를 사용해 코드 의미 구조를 보존하고, WYSIWYG 환경에서 도메인 전문가와 협업하며, 코드 상세 수준 조절 및 자동 문서화를 통해 가독성과 유지보수성을 높이는 데 중점을 둔다.
객체 지향 프로그래밍 - Is-a
Is-a 관계는 객체 지향 프로그래밍에서 한 유형이 다른 유형의 하위 유형임을 나타내는 관계로, 상속, 서브타이핑, 리스코프 치환 원칙과 관련되며, C++, Python, Java 등에서 표현된다.
객체 지향 프로그래밍 - 객체 (컴퓨터 과학)
객체는 객체 지향 프로그래밍에서 데이터와 조작을 묶어 메시지를 수신하고, 프로그램의 개념을 표현하며 가시성과 재사용성을 높이는 실체이다.

객체 지향 프로그래밍

2. 역사

현대적 의미의 객체 지향 프로그래밍에서 "객체"라는 용어는 1950년대 후반과 1960년대 초 MIT의 인공 지능 그룹에서 처음 등장했다. 이 "객체"는 식별된 속성(애트리뷰트)을 가진 LISP 원자를 지칭했다.^[3]^[4] 1960–1961년에 이반 서덜랜드가 만든 스케치패드는 또 다른 초기 MIT의 예시이다. 서덜랜드는 "객체"와 "인스턴스"의 개념을 정의했지만, 이는 그래픽 상호 작용에 특화되었다.^[5] 1968년 MIT ALGOL 버전인 AED-0은 데이터 구조와 프로시저 간의 직접적인 연결을 설정하여, 훗날 "메시지", "메서드", "멤버 함수" 등으로 불리는 개념들의 시초가 되었다.^[6]^[7]

시뮬라는 1961–1967년에 개발되었으며,^[6] 클래스와 객체, 상속 및 동적 바인딩과 같은 객체 지향 프로그래밍의 핵심 개념들을 도입했다.^[8] 객체 지향 시뮬라 프로그래밍 언어는 주로 물리 모델링과 관련된 연구자들이 사용했다.^[8]

1966년 11월, 앨런 케이는 스몰토크 프로그래밍 언어에 통합될 아이디어를 연구하기 시작했다. 케이는 1967년부터 "객체 지향 프로그래밍"이라는 용어를 사용했다.^[10] 그는 "객체 지향 프로그래밍의 아버지"라고 불리기도 하지만,^[9] 컴퓨터 과학계가 그의 개념을 온전히 채택하지 않았다고 언급했다.^[10]

1970년대 후반과 1980년대에 객체 지향 프로그래밍은 주요한 흐름으로 떠올랐다. 1979년부터 개발된 Flavors 객체 지향 Lisp는 다중 상속과 믹스인을 도입했다.^[14] 1981년 골드버그는 바이트 매거진 8월 호를 통해 스몰토크와 객체 지향 프로그래밍을 대중에게 소개했다.^[15] 1986년 컴퓨팅 기계 협회는 최초의 ''객체 지향 프로그래밍, 시스템, 언어 및 응용 프로그램에 관한 회의''(OOPSLA)를 개최했다.

1980년대 중반, Objective-C는 브래드 콕스에 의해, C++는 비야네 스트롭스트루프에 의해 개발되었다.^[12] 1985년, 베르트랑 메이어는 Eiffel 언어의 첫 번째 설계를 제작했다.

1990년대 초중반에 객체 지향 프로그래밍은 기술을 지원하는 프로그래밍 언어가 널리 사용되면서 지배적인 프로그래밍 패러다임으로 발전했다. 여기에는 비주얼 폭스프로 3.0,^[17]^[18] C++,^[19] 및 델파이가 포함되었다.

ETH 취리히에서 니클라우스 비르트와 그의 동료들은 모듈 경계 간의 타입 검사 개념을 연구했다. 모듈라-2 (1978)는 이 개념을 포함했고, 오베론 (1987)은 객체 지향, 클래스 등에 대한 독특한 접근 방식을 포함했다.

객체 지향 기능은 Ada, BASIC, 포트란, 파스칼, COBOL을 포함하여 이전에 존재하던 많은 언어에 추가되었다.

최근에는 객체 지향적이면서도 절차적 방법론과도 호환되는 파이썬과 루비와 같은 언어들이 등장했다. 썬 마이크로시스템즈에서 개발한 자바와 C# 및 VB.NET은 상업적으로 중요한 객체 지향 언어이다.

2. 1. 객체 지향 언어의 시초

객체 지향 언어의 시초는 1960년 노르웨이 컴퓨팅 센터의 올레요한 달과 크리스텐 니가드가 발표한 시뮬라 67이다.^[8] 시뮬라 67이 채택한 가장 중요한 개념은 클래스 도입으로, 이 아이디어는 스몰토크, C++ 등에도 사용되었다.^[8] 하지만 시뮬라 67 발표 이후 10여 년간 객체 지향 언어는 전혀 주목받지 못했다. 1970년대 컴퓨터 산업을 주도한 IBM, AT&T, 미 국방성 등에서 관심을 두지 않았기 때문에 실용적인 언어로 발전하지 못했지만, 학문적 가치는 인정받고 있다.

1962년 크리스텐 니가드는 노르웨이 계산 센터에서 시뮬레이션 언어 프로젝트를 시작했다. 이는 그가 이전에 사용한 몬테카를로 방법과 현실 세계 시스템을 개념화하는 작업을 기반으로 했다. 올레 요한 달이 정식으로 프로젝트에 참여하여 UNIVAC I (UNIVAC 1107)에서 작동하는 시뮬라 프로그래밍 언어가 설계되었다. 시뮬라는 클래스, 객체, 상속, 동적 바인딩 등 오늘날 객체 지향 프로그래밍에 필수적인 중요한 개념을 도입했다.^[8] 시뮬라는 프로그래밍에서 데이터 보안을 고려하여 설계되었다. 프로그래밍 데이터 보존을 위해 참조 카운트에 의한 검출 프로세스가 구현되었으며, 최종 수단으로 가비지 컬렉터가 주 기억 장치(메모리) 내의 사용되지 않은 객체를 삭제하도록 했다. 하지만 데이터 객체 개념은 1965년에는 이미 확립되었지만, private 및 public과 같은 변수의 범위 레벨에 따른 데이터 캡슐화는 접근하는 절차 또한 은폐해야 했기 때문에 시뮬라에서는 구현되지 않았다.

초기 단계에서 시뮬라는 프로그래밍 언어 ALGOL 60을 위한 절차 패키지였다. 하지만 ALGOL에 의한 제약에 불만을 느낀 연구자들은 UNIVAC ALGOL 60 컴파일러를 사용한 본격적인 프로그래밍 언어로 시뮬라를 개발하기로 했다. 달과 니가드는 1965년부터 1966년에 걸쳐 시뮬라 보급에 힘썼고 스웨덴, 독일, 소비에트 연방 등에서 시뮬라 사용이 증가했다. 1968년에는 배로스 B5000에서 널리 사용되었고 나중에는 URAL-16 컴퓨터에도 구현되었다. 1966년 달과 니가드는 시뮬라 컴파일러를 썼다. 그들은 SIMSCRIPT (자유 형식의 영어적인 범용 시뮬레이션 언어) 구현에 앤서니 호어의 레코드 클래스 개념을 도입하는 데 열심이었지만, 일반화된 프로세스 개념으로 레코드 클래스 속성을 유지하는 층과 접두사(prefix) 계열을 유지하는 층의 2층 구조로 하는 방식을 취했다. 접두사 계열을 통해 프로세스는 선행하는 정의를 참조하고 그 속성을 추가할 수 있다. 이와 같이 시뮬라는 클래스와 서브클래스 계층을 도입하고 이러한 클래스에서 객체를 생성할 수 있는 방법을 도입하게 되었다.

1972년에는 IBM System/360 및 IBM System/370 IBM 메인프레임용 시뮬라 67 컴파일러가 완성^[8]되었다. 같은 해 프랑스의 CII 10070 및 CII Iris 80 메인프레임용 시뮬라 67 컴파일러가 무상으로 제공되었다. 1974년에는 시뮬라 사용자 회가 23개국 회원을 갖게 되었다. 1975년 초 DECsystem-10 메인프레임 패밀리용 시뮬라 67 컴파일러가 무상으로 출시되었고, 같은 해 8월까지 DECsystem-10의 시뮬라 67 컴파일러는 28개 사이트에 설치되었다(그 중 22개 사이트는 북미). 객체 지향 프로그래밍 언어로서 시뮬라는 화물항에서의 선박과 적재 화물 움직임을 조사·개선하기 위한 연구와 같은 물리 모델링 연구에 종사하는 연구자에게 주로 이용되었다.^[8]

2. 2. 스몰토크

앨런 케이는 1967년부터 "객체 지향 프로그래밍"이라는 용어를 사용했다.^[10] 1970년대 제록스 PARC에서 앨런 케이, 댄 인갈스(Dan Ingalls), 아델 골드버그(Adele Goldberg (computer scientist))에 의해 스몰토크 프로그래밍 언어의 첫 번째 버전이 개발되었다. 스몰토크-72는 프로그래밍 환경을 포함했으며 동적 타이핑되었고, 처음에는 인터프리터 방식으로 실행되었으며, 컴파일되지 않았다.^[12]

스몰토크는 언어 수준에서 객체 지향성을 적용하고 그래픽 개발 환경을 갖춘 것으로 유명해졌다. 여러 버전을 거치면서 언어에 대한 관심도 커졌다.^[12] 스몰토크는 시뮬라 67에서 도입된 아이디어의 영향을 받았지만, 클래스를 동적으로 생성하고 수정할 수 있는 완전한 동적 시스템으로 설계되었다.^[13]

객체 지향 언어로서 실질적인 원조는 제록스 기업의 팰러앨토 연구소에서 앨런 케이의 책임 하에 만들어진 스몰토크이다. 이 언어 역시 시뮬라 67에서 아이디어를 얻었지만 가장 순수한 객체 지향 언어로 만들어졌으며 현재에도 인정받고 있다. 미국에서 많은 사용자를 확보하고 있다. 1970년대 말 스몰토크가 만들어질 당시 제록스에서는 세 가지 가정을 하고 이 가정에 초점을 맞추어 스몰토크의 문법과 의미를 정의하였다. 첫 번째는 전 세계의 모든 사람이 컴퓨터를 사용할 것이라는 가정이었고, 두 번째는 모든 사용자가 그래픽이 지원되는 모니터와 마우스를 기본 설비로 사용하며 윈도 환경에서 작업할 것이라는 가정이었다. 마지막으로 모든 사람이 각자의 응용 프로그램을 쉽게 개발할 수 있어야 한다는 것이었다. 첫 번째와 두 번째 가정은 현실에서 거의 사실화되었으나 마지막 가정은 제록스의 실수였다. 현재 많은 컴퓨터 사용자들은 그들의 응용 프로그램을 스스로 개발하지 않는다. 이러한 점 때문에 스몰토크의 순수성과 독창성에 비하여 크게 성공하지는 못하였다.

1981년 골드버그는 바이트 매거진 8월 호를 편집하여 스몰토크와 객체 지향 프로그래밍을 많은 독자에게 소개했다.^[15]

2. 3. 에이다

에이다는 1980년대 초 미 국방성에서 개발한 객체 지향 프로그래밍 언어이다. 미 국방성은 에이다 개발 전까지 코볼과 포트란을 이용하여 시스템을 개발하였는데, 프로젝트 규모가 커지면서 유지 및 보수 비용 문제가 발생하였다. 이 문제를 해결하기 위해 코볼과 포트란 환경의 개발을 시도했으나 한계를 느끼고 새로운 언어를 도입하게 되었다. 미 국방성은 새로운 언어에 대한 정의를 공모하였고, 여러 업체들이 제시한 언어들을 기준으로 에이다를 정의하였다. 당시 파스칼이 인기가 많아 에이다의 문법은 기본적으로 파스칼 문법을 기반으로 하였다.

에이다의 큰 특징은 예외 처리 기능의 도입이다. 이는 시스템의 신뢰도를 높이기 위한 중요한 기능이며, 미 국방성 프로젝트가 중요시하는 신뢰도를 높이기 위한 필수적인 기능이었다. 하지만 에이다는 상속 개념을 반영하지 않았고, 대부분의 객체 지향 언어가 동적 바인딩 방식을 채택하는 반면 에이다는 정적 바인딩 방식을 사용하고 있다는 큰 단점을 가지고 있었다.

2. 4. 1990년대 이후의 발전

1990년대 초반, 프로그래밍 언어 분야에서 객체 지향 언어는 많은 지원을 받으며 크게 발전했다. 이들은 스몰토크와 에이다의 기본 틀을 따르면서도, 기존 문제점들을 해결하는 방향으로 나아갔다. 특히, C++, 델파이, FoxPro 등은 GUI의 발전에 큰 영향을 받으며 함께 성장했다.

그 중 AT&T의 벨 연구소에서 비야네 스트롭스트룹 등이 개발한 C++는 가장 많은 사용자를 확보한 객체 지향 언어이다. C++는 지속적인 진화를 통해 초기에는 C에 클래스 개념만 도입된 형태였으나, 중복, 상속, 가상 함수, 추상 클래스, 예외 처리 등 다양한 기능이 추가되며 발전했다. C를 기반으로 하여 많은 프로그래머들의 인기를 얻었지만, 이로 인해 객체 지향성을 제대로 반영하지 못한다는 비판도 받았다.

1990년대 중반 이후, 자바는 가전 제품용 소프트웨어 개발을 목적으로 썬 마이크로시스템즈의 제임스 고슬링이 고안한 객체 지향 언어로 각광받았다. 1993년, 고슬링은 월드 와이드 웹에 자바를 적용하기로 결정하고 핫자바라는 웹 브라우저를 개발했으며, 이는 1995년 이후 넷스케이프사의 지원을 받게 되었다. 자바의 장점은 언어의 단순성과 플랫폼 독립성이다. 특히, 객체 지향 패러다임에 충실하게 설계되어 C++보다 오용의 소지가 적다는 평가를 받는다.

브래드 콕스가 개발한 오브젝티브-C는 C++와 마찬가지로 C와 객체 지향 언어를 혼합한 언어이다. 오브젝티브-C는 C++보다 스몰토크에 더 가까운 형태로 정의되었다.

3. 기본 구성 요소

클래스(Class): 같은 종류의 집단에 속하는 속성(attribute)과 행위(behavior)를 정의한 것으로, 객체 지향 프로그래밍의 기본적인 사용자 정의 데이터형(user defined data type)이다. 클래스는 다른 클래스나 외부 요소와 독립적으로 디자인해야 한다.
객체(Object): 클래스의 인스턴스(instance) (실제로 메모리상에 할당된 것)이다. 객체는 고유의 속성을 가지며 클래스에서 정의한 행위를 수행할 수 있다.
메서드(Method), 메시지(Message): 클래스로부터 생성된 객체를 사용하는 방법으로, 객체에 명령을 내리는 메시지이다. 메서드는 객체의 속성을 조작하는 데 사용되는 서브루틴(subroutine) 형태이며, 객체 간의 통신은 메시지를 통해 이루어진다.
변수(컴퓨터 과학): 정수, 영숫자 문자(컴퓨팅)와 같은 내장 자료형으로 형식화된 정보를 저장할 수 있다. 문자열, 리스트(추상적 자료형), 해시 테이블과 같은 자료 구조를 포함할 수 있으며, 포인터(프로그래밍)를 사용하여 변수를 결합하여 만들 수 있다.
프로시저: 함수, 메서드, 루틴 또는 서브루틴이라고도 하며, 입력을 받아 출력을 생성하고 데이터를 조작한다. 구조적 프로그래밍 구성 요소인 루프(컴퓨팅) 및 조건문(컴퓨터 프로그래밍)을 포함한다.

모듈식 프로그래밍은 프로시저를 파일 및 모듈로 그룹화하는 기능을 제공한다. 모듈은 네임스페이스를 가지므로, 한 모듈의 식별자는 다른 파일 또는 모듈에서 동일한 이름을 가진 프로시저 또는 변수와 충돌하지 않는다.

4. 특징

객체 지향 프로그래밍(OOP)의 주요 특징은 자료 추상화, 상속, 다형 개념, 동적 바인딩 등이다. 이들은 시스템의 복잡성을 제어하기 위해 서로 연관되어 작동한다.

객체 지향 프로그래밍은 객체를 사용하지만, 객체 지향 프로그래밍을 지원하는 언어라고 해서 관련 기술과 구조를 모두 직접 지원하는 것은 아니다. 크리스토퍼 J. 데이트는 객체 지향 프로그래밍에 대한 합의된 정의가 부족하여, 다른 기술(특히 관계형 기술)과 객체 지향 프로그래밍을 비교하기 어렵다고 지적했다.^[24]

객체 지향 프로그래밍 언어(OOPL)는 객체를 사용하지만, 언어 사양에서 OOP 지원을 표방하더라도 관련 기술 및 구조의 모든 것이 언어 기능에 의해 직접 지원되는 것은 아니다. 다음은 클래스 지향이나 객체 지향 언어(또는 OOP를 지원하는 멀티 패러다임 프로그래밍 언어)에서 공통적으로 나타나는 특징들이다.

변수: 정수형이나 문자와 같은 기본적인 자료형 정보, 또는 문자열, 리스트, 해시 테이블 등의 자료 구조를 저장할 수 있다.
프로시저 (함수, 메서드, 서브루틴): 입력을 받아 출력을 생성하고 데이터를 조작한다. 최근의 언어에는 루프나 조건문과 같은 구조적 프로그래밍 요소가 포함된다.
모듈형 프로그래밍 지원: 프로시저를 파일이나 모듈로 정리하는 기능을 제공한다. 모듈은 네임스페이스를 가져, 한 모듈의 식별자가 다른 모듈의 같은 이름의 프로시저나 변수와 충돌하는 것을 막는다.
서브타이핑(다형성의 한 형태): 호출하는 코드가 지원되는 계층의 어떤 클래스(부모 클래스 또는 자식 클래스)를 조작하는지 알 필요 없이, 동일한 연산 이름이라도 객체 간에 다른 동작을 할 수 있다.

4. 1. 자료 추상화

자료 추상화는 불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 프로그램을 간단히 만드는 것이다. 자료 추상화를 통해 정의된 자료형을 추상 자료형이라고 한다. 추상 자료형은 자료형의 자료 표현과 자료형의 연산을 캡슐화한 것으로 접근 제어를 통해서 자료형의 정보를 은닉할 수 있다. 객체 지향 프로그래밍에서 일반적으로 추상 자료형을 클래스, 추상 자료형의 인스턴스를 객체, 추상 자료형에서 정의된 연산을 메소드(함수), 메소드의 호출을 생성자라고 한다.^[37]

자료 추상화는 오용을 방지하기 위해 데이터가 의미적으로 관련된 함수에만 보이도록 하는 설계 패턴이다.^[36] 자료 추상화의 성공은 객체 지향 프로그래밍과 순수 함수형 프로그래밍에서 정보 은닉을 설계 원칙으로 자주 포함시키는 결과를 낳았다. 마찬가지로, 캡슐화는 외부 코드가 객체의 내부 작동에 관여하는 것을 방지하여 코드 리팩토링을 용이하게 한다. 예를 들어, 클래스 작성자가 ( "public" 메서드 호출이 동일하게 작동하는 한) 외부 코드를 변경하지 않고 해당 클래스의 객체가 내부적으로 데이터를 나타내는 방식을 변경할 수 있다. 또한 프로그래머가 특정 데이터 집합과 관련된 모든 코드를 동일한 클래스에 넣도록 장려하여 다른 프로그래머가 쉽게 이해할 수 있도록 구성한다. 캡슐화는 결합도를 줄이도록 장려하는 기술이다.^[37]

초기 설계는 지역 (또는 메서드) 변수, 개인 변수 (객체 지향 프로그래밍에서) 및 전역 (또는 공개) 변수 순으로 가능한 가장 제한적인 가시성을 사용하고 필요할 때만 확장하는 것이 권장된다. 이렇게 하면 가시성 변경으로 인해 기존 코드가 무효화되는 것을 방지한다.^[38]

클래스가 호출 코드가 내부 객체 데이터에 액세스하는 것을 허용하지 않고 메서드를 통해서만 액세스를 허용하는 경우, 이는 또한 정보 은닉의 한 형태이다. 일부 언어 (예: Java)는 클래스가 액세스 제한을 명시적으로 적용하도록 허용한다. 예를 들어, 내부 데이터를 `private` 키워드로 표시하고, 클래스 외부의 코드에서 사용하기 위한 메서드를 `public` 키워드로 지정한다. 메서드는 `protected` (동일한 클래스 및 해당 하위 클래스에서 액세스를 허용하지만 다른 클래스의 객체에서는 허용하지 않음)과 같은 공용, 개인 또는 중간 수준으로 설계할 수도 있다. 다른 언어 (예: Python)에서는 이 규칙이 관례에 의해서만 적용된다 (예: `private` 메서드는 밑줄로 시작하는 이름을 가질 수 있다). C#, Swift 및 Kotlin 언어에서 `internal` 키워드는 클래스와 동일한 어셈블리, 패키지 또는 모듈에 있는 파일에만 액세스를 허용한다.^[39]

프로그래밍 언어, 특히 객체 지향 언어에서 추상화에 대한 강조는 매우 중요하다. 객체 지향 언어는 데이터 추상화를 통합하도록 유형의 개념을 확장하여 메서드를 통한 내부 데이터에 대한 액세스를 제한하는 것의 중요성을 강조한다.^[40]

4. 2. 캡슐화

자료 추상화의 성공은 객체 지향 프로그래밍과 순수 함수형 프로그래밍에서 정보 은닉을 설계 원칙으로 자주 포함시키는 결과를 낳았다. 마찬가지로, 캡슐화는 외부 코드가 객체의 내부 작동에 관여하는 것을 방지한다. 이는 코드 리팩토링을 용이하게 한다.^[37] 예를 들어, 클래스 작성자가 ( "public" 메서드 호출이 동일하게 작동하는 한) 외부 코드를 변경하지 않고 해당 클래스의 객체가 내부적으로 데이터를 나타내는 방식을 변경할 수 있다. 또한 프로그래머가 특정 데이터 집합과 관련된 모든 코드를 동일한 클래스에 넣도록 장려하여 다른 프로그래머가 쉽게 이해할 수 있도록 구성한다. 캡슐화는 결합도를 줄이도록 장려하는 기술이다.

객체 지향 프로그래밍에서 객체는 내부 코드와 외부 코드를 분리하고 추상화 및 캡슐화를 구현하는 데 사용할 수 있는 계층을 제공한다.^[37] 외부 코드는 특정 입력 매개변수 집합을 사용하여 특정 인스턴스 메서드를 호출하거나, 인스턴스 변수를 읽거나, 인스턴스 변수에 기록함으로써 객체를 사용할 수 있다.

초기 설계는 지역 (또는 메서드) 변수, 개인 변수 (객체 지향 프로그래밍에서) 및 전역 (또는 공개) 변수 순으로 가능한 가장 제한적인 가시성을 사용하고 필요할 때만 확장하는 것이 권장된다.^[38] 이렇게 하면 가시성 변경으로 인해 기존 코드가 무효화되는 것을 방지한다.

클래스가 호출 코드가 내부 객체 데이터에 액세스하는 것을 허용하지 않고 메서드를 통해서만 액세스를 허용하는 경우, 이는 또한 정보 은닉의 한 형태이다. 일부 언어 (예: Java)는 클래스가 액세스 제한을 명시적으로 적용하도록 허용한다. 예를 들어, 내부 데이터를 `private` 키워드로 표시하고, 클래스 외부의 코드에서 사용하기 위한 메서드를 `public` 키워드로 지정한다. 메서드는 `protected` (동일한 클래스 및 해당 하위 클래스에서 액세스를 허용하지만 다른 클래스의 객체에서는 허용하지 않음)과 같은 공용, 개인 또는 중간 수준으로 설계할 수도 있다. 다른 언어 (예: Python)에서는 이 규칙이 관례에 의해서만 적용된다 (예: `private` 메서드는 밑줄로 시작하는 이름을 가질 수 있다). C#, Swift 및 Kotlin 언어에서 `internal` 키워드는 클래스와 동일한 어셈블리, 패키지 또는 모듈에 있는 파일에만 액세스를 허용한다.^[39]

4. 3. 상속

상속은 새로운 클래스가 기존 클래스의 자료와 연산을 이용할 수 있게 하는 기능이다. 상속을 받는 새로운 클래스를 부클래스, 파생 클래스, 하위 클래스, 자식 클래스라고 하며, 새로운 클래스가 상속하는 기존의 클래스를 기반 클래스, 상위 클래스, 부모 클래스라고 한다.^[74] 상속을 통해 기존 클래스를 상속받은 하위 클래스를 이용해 프로그램의 요구에 맞추어 클래스를 수정할 수 있고, 클래스 간의 종속 관계를 형성함으로써 객체를 조직화할 수 있다.

다중 상속은 클래스가 2개 이상의 클래스로부터 상속받을 수 있게 하는 기능이다. 클래스들의 기능이 동시에 필요할 때 용이하나 클래스의 상속 관계에 혼란을 줄 수 있고(예: 다이아몬드 상속) 프로그래밍 언어에 따라 사용 가능 유무가 다르므로 주의해서 사용해야 한다. 자바는 다중 상속을 지원하지 않는다.

OOP 언어는 일반적으로 상속을 통해 코드 재사용성과 확장성을 지원하며, 이는 클래스 또는 프로토타입 형태로 나타난다.^[73] 이러한 상속 형태는 상당히 다르지만, '객체'와 '인스턴스'의 개념을 정의하는 데 유사한 용어가 사용된다.

클래스를 지원하는 언어는 대개 상속을 지원한다. 상속은 클래스를 "○○는 △△이다"라는 관계("is-a-type-of")의 계층 구조로 배치하는 것이다. 예를 들어, `Employee` 클래스가 `Person` 클래스를 상속하는 경우, 부모 클래스에서 사용할 수 있는 데이터나 메서드는 자식 클래스에서도 같은 이름으로 사용할 수 있다. `Person` 클래스가 `first_name`과 `last_name`이라는 변수를 `make_full_name()`이라는 메서드로 정의한 경우, 이러한 정의는 `Employee` 클래스에서도 사용할 수 있다. 더불어, `Employee` 클래스에는 변수 `position`과 `salary`를 추가할 수도 있다. 이 기법은 같은 절차나 데이터 정의를 쉽게 재사용할 수 있을 뿐만 아니라, 현실 세계의 관계를 직관적으로 반영할 수 있는 가능성을 넓힌다. 개발자는 데이터베이스의 테이블이나 프로그래밍의 서브루틴을 다루는 대신, 개발 애플리케이션의 사용자가 더 친숙한 도메인의 객체를 다룰 수 있다.^[74]

서브 클래스는 슈퍼 클래스에서 정의된 메서드를 오버라이드할 수 있다. 언어에 따라 다중 상속이 가능하지만, 다중 상속에서는 오버라이드의 해결이 복잡해질 수 있다.

상속보다 조합은 상속 대신 조합을 사용하여 has-a 관계를 구현할 것을 제창하고 있다. 예를 들어, Employee 클래스는 Person 클래스를 상속하는 대신, 각 Employee 객체 내부에 Person 객체를 포함함으로써, 만약 Person 클래스가 공개된 속성이나 메서드를 다수 가지고 있어도 외부 코드에서는 숨길 수 있도록 한다. Go와 같이, 상속을 전혀 지원하지 않는 언어도 존재한다.

개방/폐쇄 원칙은 클래스나 메서드는 "확장에는 열려 있지만 변경에는 닫혀 있어야 한다"는 원칙을 제창하고 있다.

위임 또한, 상속 대신에 이용할 수 있는 언어 기능이다.

상속은 의미론적으로 is-a 관계를 만들기 때문에, 서브 클래스에서 인스턴스화된 객체는 슈퍼 클래스에서 인스턴스화된 객체를 대신하여 항상 ''안전하게'' 사용할 수 있다고 추론하는 것은 직관적이지만, 이러한 직관은 대부분의 OOPL, 특히 가변 객체를 허용하는 언어에서는 오류이다. (가변 객체를 갖는) OOPL의 타입 검사기에 의해 강제되는 부분 타입 지정 (부분 타입 다형성/서브타이핑 다형성)에서는 어떤 상황에서도 행동의 부분 타입 지정을 보장할 수 없다. 행동의 부분 타입 지정은 일반적으로 결정 불가능하며, 프로그램 (컴파일러)에서는 구현할 수 없다. 클래스나 객체의 계층은 문법 오류로는 감지할 수 없는 사용법이 있을 가능성을 고려하여 신중하게 설계해야 한다. 이 문제는 리스코프 치환 원칙이라고도 알려져 있다.

4. 4. 다형성

다형성 개념은 한 요소에 여러 개념을 넣어 놓는 것으로, 보통 오버라이딩(같은 이름의 메소드가 여러 클래스에서 다른 기능을 하는 것)이나 오버로딩(같은 이름의 메소드가 인자의 개수나 자료형에 따라서 다른 기능을 하는 것)을 의미한다. 다형성 개념을 통해 프로그램 안의 객체 간의 관계를 조직적으로 나타낼 수 있다.

서브타이핑은 다형성의 한 형태로서, 호출 코드가 지원되는 계층 구조에서 작동하는 클래스(부모 클래스 또는 자손 클래스 중 하나)에 독립적일 수 있는 경우이다. 상속 계층 구조 내의 객체 간에 동일한 연산 이름은 다르게 동작할 수 있다.

예를 들어, Circle과 Square 타입의 객체는 Shape이라는 공통 클래스에서 파생된다. 각 Shape 타입의 Draw 함수는 호출 코드가 그려지는 특정 Shape 타입에 관계없이 자체적으로 그리는데 필요한 것을 구현한다.

이는 클래스 계층 구조 외부의 코드를 단순화하고 강력한 관심사 분리를 가능하게 하는 또 다른 유형의 추상화이다.

4. 5. 동적 바인딩

동적 바인딩은 실행 시간 중에 일어나거나 실행 과정에서 변경될 수 있는 바인딩으로, 컴파일 시간에 완료되어 변화하지 않는 정적 바인딩과 대비되는 개념이다. 동적 바인딩은 프로그램의 한 개체나 기호를 실행 과정에 여러 속성이나 연산에 바인딩함으로써 다형성 개념을 실현한다.

객체가 메서드 호출에 응답하여 실행할 프로시저 코드를 선택하는 것은 객체의 책임이며, 일반적으로 객체와 관련된 테이블에서 런타임에 메서드를 조회하여 수행한다. 이 기능을 동적 디스패치라고 한다.^[1] 호출 변동성이 메서드가 호출되는 객체의 단일 유형 이상에 의존하는 경우(즉, 최소 하나의 다른 매개변수 객체가 메서드 선택에 관여하는 경우) 다중 디스패치라고 한다.^[2] 메서드 호출은 ''메시지 전달''이라고도 한다. 이는 디스패치를 위해 객체에 전달되는 메시지(메서드 이름과 입력 매개변수)로 개념화된다.^[3]

디스패치는 상속과 상호 작용한다. 주어진 객체나 클래스에 메서드가 없는 경우, 디스패치는 부모 객체나 클래스에 위임되며, 상속 체인을 따라 계속 위임된다.^[4]

객체의 일반적인 특징은 메서드가 객체에 연결되어 객체의 데이터 필드에 접근하고 수정할 수 있다는 것이다. 이러한 종류의 객체 지향 프로그래밍(OOP)에서는 현재 객체를 참조하기 위해 this 또는 self와 같은 특수한 이름이 사용된다.^[5] 오픈 재귀를 지원하는 언어에서 객체 메서드는 이 이름을 사용하여 동일한 객체의 다른 메서드(자신 포함)를 호출할 수 있다. 이 변수는 ''지연 바인딩''된다. 이는 한 클래스에 정의된 메서드가 나중에 해당 서브클래스에서 정의된 다른 메서드를 호출할 수 있도록 한다.^[6]

메서드 호출에 따라 실행할 절차의 코드를 선택하는 것은 외재하는 코드가 아닌 객체의 책임이다. 전형적으로, 객체와 관련된 테이블에서 런타임에 메서드를 검색하지만, 이 기능은 동적 디스패치로 알려져 있으며, 추상 데이터 타입 (또는 모듈)에서 모든 인스턴스의 연산이 정적으로 구현되는 것과는 대조적이다.^[7]

메서드 호출은 메시지 전달이라고도 한다. 이것은 메서드 호출을 디스패치를 위해 객체에 전달되는 메시지 (메서드 이름과 입력 인수)로 개념화한 것이다.^[8]

5. 장점

객체 지향 프로그래밍(OOP)은 소프트웨어 공학에서 소프트웨어의 질을 높이기 위해 사용되는 방법론이다. OOP는 강한 응집력과 약한 결합력을 지향하는데, 이는 문제 해결을 위한 데이터를 클래스에 모아 응집력을 강화하고, 클래스 간 독립적인 디자인을 통해 결합력을 약하게 만들기 때문이다.^[77]

OOP는 코드 재사용성과 소프트웨어 유지보수를 향상시키기 위해 발전해왔다.^[77] 그러나 초기에는 제어 흐름의 투명한 표현에 대한 고려가 부족했고, 컴파일러가 임의로 처리하는 것으로 여겨졌다. 하지만 병렬 하드웨어와 멀티스레드 코딩의 중요성이 커지면서 투명한 제어 흐름 개발이 중요해지고 있다.^[78]^[79]^[80]^[81]

6. 객체 지향 프로그래밍 언어

다음은 대표적인 객체 지향 프로그래밍 언어들이다.

시뮬라 67(Simula 67^영어): 최초의 객체 지향 언어로 알려져 있다.
스몰토크
비주얼 베이직 닷넷
오브젝티브-C
C++
C#
Dart
자바
객체지향 파스칼
델파이
파이썬
펄
루비
액션스크립트
ASP
스위프트

시뮬라 (1967)는 일반적으로 객체 지향 언어의 주요 특징을 가진 최초의 언어로 인정받고 있다. 스몰토크 (1972년 ~ 1980년)는 OOP 이론의 상당 부분이 개발된 언어이기도 하다. 객체 지향성의 정도에 따라 다음과 같이 구분할 수 있다.^[45]

"순수" OO 언어: 문자, 구두점과 같은 기본 요소부터 클래스, 프로토타입, 블록, 모듈 등에 이르기까지 모든 것을 일관되게 객체로 취급한다. 이러한 언어들은 OO 방식을 촉진하고 심지어 강제하기 위해 특별히 설계되었다. 예시: 루비, 스칼라, 스몰토크, 에펠, 에메랄드, JADE, 셀프, 라쿠.
주로 OO 프로그래밍을 위해 설계되었지만 일부 절차적 요소를 가진 언어: 예시: 자바, 파이썬, C++, C#, 델파이/오브젝트 파스칼, VB.NET.
역사적으로 절차적 언어였지만 일부 OO 기능으로 확장된 언어: 예시: PHP, 자바스크립트, 펄, 비주얼 베이직, MATLAB, COBOL 2002, 포트란 2003, ABAP, Ada 95, 파스칼.
객체의 대부분의 특징(클래스, 메서드, 상속)을 가지고 있지만 독창적인 형태로 구현된 언어: 예시: 오베론 (오베론-1 또는 오베론-2).
추상 자료형을 지원하여 OO 프로그래밍과 유사하게 사용할 수 있지만 객체 지향의 모든 기능을 갖추지 않은 언어: 여기에는 객체 기반 및 프로토타입 기반 언어가 포함된다. 예시: 자바스크립트, Lua, 모듈라-2, CLU.

최근 몇 년 동안 객체 지향 프로그래밍은 특히 동적 프로그래밍 언어에서 인기를 얻고 있다. 파이썬, 파워셸, 루비 및 그루비는 OOP 원칙을 기반으로 구축된 동적 언어이다. 펄과 PHP는 펄 5와 PHP 4 이후부터, 콜드퓨전은 버전 6부터 객체 지향 기능을 추가해 왔다.

인터넷상의 HTML, XHTML, XML 문서의 문서 객체 모델은 자바스크립트/ECMAScript 언어에 바인딩되어 있다. 자바스크립트는 프로토타입 기반 프로그래밍 언어이며, 클래스 기반 프로그래밍과 달리 클래스에서 상속하는 대신 프로토타입에서 복제하여 사용한다. 루아도 같은 방식을 취한다.

7. 디자인 패턴

객체 지향 설계의 과제를 해결하는 한 가지 방법은 소프트웨어 설계에서 흔히 발생하는 문제에 대한 해결 패턴인 디자인 패턴을 사용하는 것이다.

에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시디스가 1994년에 출판한 ''디자인 패턴: 재사용 가능한 객체 지향 소프트웨어의 요소''는 "사천왕"으로 불리며 객체 지향 프로그래밍의 기능과 함정을 탐구하고, 23가지 일반적인 프로그래밍 문제와 이를 해결하기 위한 패턴을 설명하는 책이다.

7. 1. 객체 패턴

다음은 객체 지향 프로그래밍(OOP) 객체를 위한 주목할 만한 소프트웨어 디자인 패턴이다.^[53]

함수 객체: 단일 메서드(C++에서는 함수 연산자, `operator()`)를 사용하여 함수와 유사하게 작동한다.

불변 객체: 생성 후 상태가 변경되지 않는다.

일급 객체: 제한 없이 사용할 수 있다.

컨테이너 객체: 다른 객체를 포함한다.

팩토리 객체: 다른 객체를 생성한다.

메타객체: 다른 객체를 생성할 수 있는 객체 (객체일 필요는 없는 클래스와 비교).

프로토타입 객체: 복사하여 다른 객체를 생성할 수 있는 특수화된 메타객체이다.

싱글톤 객체: 프로그램 수명 동안 해당 클래스의 유일한 인스턴스이다.

필터 객체: 데이터 스트림을 입력으로 받아 객체의 출력으로 변환한다.

객체 안티 패턴의 예로, 갓 오브젝트는 너무 많은 것을 알고 있거나 수행한다.

7. 2. GoF 디자인 패턴

''디자인 패턴: 재사용 가능한 객체 지향 소프트웨어의 요소''는 1994년에 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시디스가 출판한 영향력 있는 책으로, 흔히 "사천왕"으로 불린다. 이 책은 객체 지향 프로그래밍의 기능과 함정을 탐구하고, 23가지 일반적인 프로그래밍 문제와 이를 해결하기 위한 패턴을 설명한다.

이 책에서 설명하는 패턴은 다음과 같다.

'''생성 패턴'' (5): 팩토리 메서드 패턴, 추상 팩토리 패턴, 싱글톤 패턴, 빌더 패턴, 프로토타입 패턴
'''구조 패턴'' (7): 어댑터 패턴, 브리지 패턴, 컴포지트 패턴, 데코레이터 패턴, 퍼사드 패턴, 플라이웨이트 패턴, 프록시 패턴
'''행동 패턴'' (11): 책임 연쇄 패턴, 커맨드 패턴, 인터프리터 패턴, 반복자 패턴, 중재자 패턴, 메멘토 패턴, 옵저버 패턴, 상태 패턴, 전략 패턴, 템플릿 메서드 패턴, 방문자 패턴

8. 객체 지향과 데이터베이스

클라이언트-서버 환경에서 서비스를 요청하기 위해 컴퓨터 간에 흐르는 메시지는 클라이언트와 서버 모두에 알려진 클래스 객체에 의해 정의된 객체의 선형화로 설계될 수 있다. 예를 들어, 간단한 선형화된 객체는 길이 필드, 클래스를 식별하는 코드 포인트 및 데이터 값으로 구성된다. 더 복잡한 예는 명령의 길이와 코드 포인트로 구성된 명령과 명령의 매개변수를 나타내는 선형화된 객체로 구성된 값으로 구성된다. 이러한 각 명령은 서버에서 해당 명령을 인식하고 요청된 서비스를 제공할 수 있는 클래스(또는 상위 클래스)의 객체로 전달되어야 한다. 클라이언트와 서버는 복잡한 객체 지향 구조로 모델링하는 것이 가장 좋다. 분산 데이터 관리 아키텍처(DDM)는 이러한 접근 방식을 취하여 클래스 객체를 사용하여 공식적인 계층 구조의 네 가지 레벨에서 객체를 정의했다.

메시지를 구성하는 데이터 값(예: 길이, 코드 포인트 및 데이터 값)을 정의하는 필드.
메시지 및 매개변수에 대한 스몰토크 프로그램에서 발견되는 것과 유사한 객체 및 객체 모음.
IBM i 객체와 유사한 관리자(예: 파일 디렉토리, 메타데이터 및 레코드로 구성된 파일) 관리자는 개념적으로 포함된 객체에 대한 메모리 및 처리 리소스를 제공한다.
디렉토리 서비스, 보안 및 동시성 제어와 같은 측면을 지원하는 전체 처리 환경을 구현하는 데 필요한 모든 관리자로 구성된 클라이언트 또는 서버.

DDM의 초기 버전은 분산 파일 서비스를 정의했다. 이후 분산 관계형 데이터베이스 아키텍처(DRDA)의 기반이 되도록 확장되었다.

관계형 데이터베이스 관리 시스템(RDBMS)과 객체 지향 프로그래밍은 2006년 현재 소프트웨어에서 매우 널리 사용되고 있다. 관계형 데이터베이스는 객체를 직접 저장하지 않기 때문에 (일부 RDBMS는 이를 근사하기 위한 객체 지향 기능을 가지고 있지만), 두 세계를 연결해야 할 필요가 일반적으로 존재한다. 객체 지향 프로그래밍의 접근 방식과 데이터 패턴을 관계형 데이터베이스와 연결하는 문제는 객체-관계 임피던스 불일치라고 알려져 있다. 이 문제를 해결하기 위한 몇 가지 접근 방식이 있지만, 단점이 없는 일반적인 해결책은 없다.^[54] 가장 일반적인 접근 방식 중 하나는 통합 개발 환경 (IDE) 언어인 Visual FoxPro나 Java Data Objects 및 Ruby on Rails의 ActiveRecord와 같은 라이브러리에서 발견되는 객체-관계 매핑이다.

RDBMS를 대체하는 데 사용할 수 있는 객체 데이터베이스도 있지만, RDBMS만큼 기술적, 상업적으로 성공하지는 못했다.

9. 비판

TIOBE 프로그래밍 언어 인기 지수 그래프 (2002년~2023년). 2000년대에 객체 지향 자바(주황색)와 절차적 C(짙은 파란색)가 1위 자리를 놓고 경쟁했다.

C++, 자바, 파이썬과 같이 널리 사용되는 많은 언어들이 객체 지향 기능을 제공한다. 과거에는 객체 지향 프로그래밍이 널리 받아들여졌지만,^[46] 최근에는 개발자 커뮤니티에서 객체 지향 프로그래밍을 비판하고 함수형 프로그래밍을 선호하며 이러한 기능을 피할 것을 권장하는 에세이가 매우 인기를 얻고 있다.^[47] 폴 그래엄은 대규모 기업 내에서 OOP의 인기가 "크고 (자주 변경되는) 평범한 프로그래머 그룹" 때문이라고 주장했다. 그래엄에 따르면 OOP가 부과하는 규율은 한 명의 프로그래머가 "너무 많은 피해를 주는 것"을 막아준다.^[48] 에릭 S. 레이먼드는 유닉스 프로그래머이자 오픈 소스 소프트웨어 옹호자로, 객체 지향 프로그래밍을 "유일한 진정한 해결책"으로 제시하는 주장에 대해 비판적이다.^[41]

리처드 펠드먼은 이러한 언어들이 객체 지향 기능을 추가하여 모듈성을 개선했을 수는 있지만, 객체 지향적이라는 이유 외에 다른 이유로 인기를 얻었다고 주장한다.^[49] 로렌스 크루브너는 기사에서 다른 언어(LISP 방언, 함수형 언어 등)에 비해 OOP 언어가 고유한 강점을 가지고 있지 않으며, 불필요한 복잡성을 크게 증가시킨다고 주장했다.^[50] 포톡 등의 연구에 따르면 OOP와 절차적 접근 방식 간의 생산성에서 유의미한 차이가 나타나지 않았다.^[51] 루카 카르델리는 OOP 코드가 절차적 코드보다 "본질적으로 덜 효율적"이며, OOP의 컴파일 시간이 더 오래 걸릴 수 있다고 주장했다.^[52]

참조

_[1] 논문 Object-Oriented Simulation of systems with sophisticated control
_[2] 서적 Java Software Solutions Foundations of Programming Design 6th ed Pearson Education Inc.
_[3] 논문 LISP I Programmers Manual https://web.archive.[...] Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory 1969-03-01
_[4] 서적 LISP 1.5 Programmer's Manual https://archive.org/[...] MIT Press
_[5] 학회 Sketchpad: a man-machine graphical communication system AFIPS Press 1963-05-01
_[6] 논문 The development of the SIMULA languages 1978-08-01
_[7] 웹사이트 The first software engineering language http://www.csail.mit[...] MIT Computer Science and Artificial Intelligence Laboratory 2010-05-13
_[8] 논문 Compiling Simula: A historical study of technological genesis https://web.archive.[...] 2018-03-03
_[9] 서적 Seven Concurrency Models in Seven Weeks: When Threads Unravel https://books.google[...] Pragmatic Bookshelf 2014-06-30
_[10] 웹사이트 Dr. Alan Kay on the Meaning of "Object-Oriented Programming" http://www.purl.org/[...] 2010-02-11
_[11] 기술보고서 An Access Control Facility for Programming Languages http://csg.csail.mit[...] 1976-04-01
_[12] 서적 Touch of Class: Learning to Program Well with Objects and Contracts Springer Science & Business Media
_[13] 논문 The early history of Smalltalk 1993-03-01
_[14] 학회 Object-Oriented Programming with Flavors https://www.cs.tufts[...] 2022-03-17
_[15] 뉴스 Introducing the Smalltalk Zoo https://computerhist[...] 2020-12-17
_[16] 학회 LOOPS: data and object oriented Programming for Interlisp https://www.markstef[...] 1982
_[17] 간행물 Visual FoxPro 3.0 http://www.foxprohis[...] FoxPro 1995-06-01
_[18] 간행물 Reviewers Guide to Visual FoxPro 3.0 http://www.dfpug.de/[...] DFpug.de 1995
_[19] 서적 Object Oriented Programming with C++, 1E https://books.google[...] Vikas Publishing House Pvt Limited 2009-11-01
_[20] 문서 The Quarks of Object-Oriented Development
_[21] 서적 Concepts in programming languages Cambridge University Press
_[22] 서적 Programming language pragmatics Morgan Kaufmann
_[23] 서적 Types and Programming Languages MIT Press
_[24] 서적 Introduction to Database Systems
_[25] 서적 Software Engineering with Ada https://en.wikiquote[...] Addison Wesley
_[26] 서적 Foundation for Future Database Systems: The Third Manifesto
_[27] 웹사이트 Less is exponentially more https://commandcente[...] 2016-10-01
_[28] 웹사이트 Stevey's Blog Rants: Execution in the Kingdom of Nouns http://steve-yegge.b[...] 2020-05-20
_[29] 강연 Are We There Yet? http://www.infoq.com[...] 2009-11-01
_[30] 웹사이트 STLport: An Interview with A. Stepanov http://www.stlport.o[...] 2010-04-21
_[31] 서적 Prototype-based programming: concepts, languages and applications Springer 1999
_[32] 웹사이트 Is Go an object-oriented language? https://golang.org/d[...] 2019-04-13
_[33] 학회 Object-Oriented Programming without Inheritance (Invited Talk) https://www.youtube.[...] 2015
_[34] 웹사이트 A few years ago I saw this page http://plus.google.c[...] 2016-10-01
_[35] 메일링리스트 [9fans] Re: Threads: Sewing badges of honor onto a Kernel http://groups.google[...] 2016-11-17
_[36] 웹사이트 Uncle Bob SOLID principles https://www.youtube.[...] 2018-08-02
_[37] 서적 Object Oriented Software Engineering https://archive.org/[...] Addison-Wesley ACM Press
_[38] 서적 Object-Oriented Design with ABAP: A Practical Approach Apress 2017
_[39] 웹사이트 What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes https://softwaregeek[...] 2023-01-05
_[40] 학술지 On understanding types, data abstraction, and polymorphism 1985-12-10
_[41] 웹사이트 The Art of Unix Programming: Unix and Object-Oriented Languages http://www.catb.org/[...] 2003
_[42] 서적 Coders at Work: Reflections on the Craft of Programming http://www.codersatw[...]
_[43] 서적 Thinking Forth http://thinking-fort[...]
_[44] 웹사이트 Don't Repeat Yourself http://wiki.c2.com/?[...]
_[45] 웹사이트 The Emerald Programming Language http://www.emeraldpr[...] 2011-02-26
_[46] 서적 ECOOP 2008 – Object-Oriented Programming 2008
_[47] 뉴스 Why Are So Many Developers Hating on Object-Oriented Programming? https://thenewstack.[...] 2019-08-21
_[48] 웹사이트 Why ARC isn't especially Object-Oriented. http://www.paulgraha[...] PaulGraham.com
_[49] 웹사이트 Why Isn't Functional Programming the Norm? https://www.youtube.[...] 2019-09-30
_[50] 웹사이트 Object Oriented Programming is an expensive disaster which must end http://www.smashcomp[...] smashcompany.com
_[51] 학술지 Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment http://www.csm.ornl.[...]
_[52] 학술지 Bad Engineering Properties of Object-Oriented Languages http://lucacardelli.[...]
_[53] 웹사이트 Design Principles and Design Patterns http://www.objectmen[...]
_[54] 웹사이트 The Vietnam of Computer Science http://blogs.tednewa[...] Interoperability Happens 2006-06-26
_[55] 간행물 OOOP – The Third "O" Solution: Open OOP Object Management Group
_[56] 학술지 Good ideas, through the looking glass https://pdfs.semanti[...] 2006-01-23
_[57] 웹사이트 Execution in the Kingdom of Nouns http://steve-yegge.b[...] steve-yegge.blogspot.com 2006-03-30
_[58] 웹사이트 What's Wrong with OOP http://zaemis.blogsp[...] zaemis.blogspot.com 2009-06-11
_[59] 웹사이트 A Realistic Look at Object-Oriented Reuse http://www.drdobbs.c[...] drdobbs.com 1998-01-01
_[60] 웹사이트 Flaws of Object Oriented Modeling http://software.inte[...] Intel Software Network 2008-08-22
_[61] 웹사이트 Multithreading is a verb not a noun http://blogs.techrep[...] techrepublic.com 2007-10-01
_[62] 웹사이트 HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions http://support.micro[...] support.microsoft.com 2008-08-22
_[63] 웹사이트 Some thoughts on teaching FP http://existentialty[...] Existential Type Blog 2011-04-17
_[64] 웹사이트 Subtyping and Inheritance for Categorical Datatypes https://www.cs.ru.nl[...]
_[65] 서적 A Theory of Objects http://portal.acm.or[...] Springer-Verlag New York, Inc.
_[66] 웹사이트 Summary of Fox releases http://www.foxprohis[...] 1995-06-01
_[67] 웹사이트 Foxprohistory.org http://www.foxprohis[...]
_[68] 웹사이트 1995年のVisual FoxPro 3.0 レビュー/ガイド http://www.dfpug.de/[...]
_[69] 서적 Object Oriented Programming with C++, 1E https://books.google[...] 2009-11-01
_[70] 웹사이트 Delphiがトップ20位から脱落 https://news.mynavi.[...] マイナビTECH+
_[71] 보고서 From Modula to Oberon and the programming language Oberon https://doi.org/10.3[...] Wiley
_[72] 웹사이트 共通型システム https://docs.microso[...]
_[73] 서적 Software Engineering with Ada https://en.wikiquote[...] Addison Wesley
_[74] 서적 Object Oriented Software Engineering https://archive.org/[...] Addison-Wesley ACM Press
_[75] 서적 型システム入門オーム社
_[76] 웹사이트 The Vietnam of Computer Science http://blogs.tednewa[...] Interoperability Happens 2006-06-26
_[77] 웹사이트 A Realistic Look at Object-Oriented Reuse http://www.drdobbs.c[...] drdobbs.com 1998-01-01
_[78] 웹사이트 Flaws of Object Oriented Modeling http://software.inte[...] Intel Software Network 2008-08-22
_[79] 웹사이트 Multithreading is a verb not a noun http://blogs.techrep[...] techrepublic.com 2007-10-01
_[80] 웹사이트 HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions http://support.micro[...] support.microsoft.com 2008-08-22
_[81] 웹사이트 Some thoughts on teaching FP http://existentialty[...] Existential Type Blog 2011-04-17
_[82] 학술지 Object-Oriented Design: A Responsibility-Driven Approach 1989
_[83] 웹사이트 Michael Feathers https://wiki.c2.com/[...]